home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16224 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: news-m01.ny.us.ibm.net!usenet
  2. From: mshan@ibm.net  (Mike Shannon)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 10 Apr 1996 00:03:15 GMT
  6. Message-ID: <4kets3$ic0@news-s01.ny.us.ibm.net>
  7. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> <dewar.829048603@schonberg>
  8. Reply-To: mshan@ibm.net (Mike Shannon)
  9. NNTP-Posting-Host: slip129-37-236-83.tx.us.ibm.net
  10. X-Newsreader: IBM NewsReader/2 v1.2
  11.  
  12. In <dewar.829048603@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
  13.  
  14. >There are two possible semantics that ould
  15. >be defined for read (buffer must be at least size of the read argument,
  16. >or buffer must be at least size of data read). Both are easy to specify,
  17. >both are easy to implement. You cannot rely on common sense
  18. > ...
  19.  
  20. I'm a latecomer to this dispute, but this is not smart:
  21.  
  22.     char buf[100];
  23.  
  24.     read(fd,buf,1000);
  25.  
  26. Common sense, which tells me not to do such things, is a welcome ally.
  27.  
  28. >We are after all dealing with a language interface where in practice the
  29. >proper check (whichever it is) cannot be made, because the called routine
  30. >does not know the length of the buffer passed. I think a natural default
  31. >assumption, in the absence of any statement to the contrary, is that the
  32. >bytes are blindly read into the buffer, and disaster strikes if the number
  33. >of bytes read is greater than the buffer length, but otherwise all is well.
  34. >Unless there is a VERY clear statement of semantics to the contrary, I
  35. >don't see how anyone can call code that makes this assumption obviously
  36. >broken.
  37.  
  38. SIGSEGV is invited, not by any "statement of semantics", but by careless
  39. code. If you use these functions without reasonable care, then you
  40. experience the consequences. If you do this for a living, you learn not
  41. to waste time on unnecessary chances.
  42.  
  43. >Specs need to be made precise,
  44. >so that a caller knows EXACTLY what the requirements are without having
  45. >to guess, or, worse still, examine the actual implementation code.
  46.  
  47. Good specs do not write good code - good programmers do.
  48.  
  49. By the way, how did all this get started?
  50.  
  51. Mike Shannon
  52. Houston, Texas
  53.  
  54. <!>  Once we had computers and dumb terminals.
  55. <!>  Now we have computers and stupid terminals.
  56. <!>  Thanks, Microsoft.
  57.  
  58.